Project: gujin boot/system loader: Document Manager: Display Document

Submit new documentation | View Documentation | AdminFAQ Questions:

The Gujin description at freshmeat:
Gujin is a PC boot loader which can analyze your filesystems. It finds the Linux kernel images available, as well as other bootable partitions (for *BSD, MS-DOS, Windows, etc.), and displays a graphical menu for selecting which system to boot. Because it understand the structure of Linux kernel images, Gujin does not need LILO and can even load very big kernels. There is no need to execute anything after making a new kernel: just copy the kernel image file into the "/boot" directory. Gujin is written almost entirely in C with GCC, and it fully executes in real mode to be as compatible as possible.

Some of the reasons I think of:
- The boot floppy and/or the boot hard drive do not depend on the physical position of the file on the drive: you can create a new kernel, copy it in /boot, rename it (as long as its name begin with "vmlinuz", "zImage" or "bzImage") and just reboot.
- The boot sector do not need to be modified each time you build a new kernel (risk of unbootable system).
- All partitions are checked (limits outside of the disk, partition overlap, filesystem FAT12/16/32 and E2/3FS bigger than the partition) just in case you used a buggy partitioning software.
- disks SMART status (health of the hard disks) are checked and reported if error or SMART present but not enabled. IDE passwords are frozen.
- The boot sector (first 512 bytes) saves register initial value, you should be able to load whatever OS (WinNT...) without _any_ problem.
- The complete process is protected by checksums, so you can detect easily bad sectors on the floppy/HD, or recover from a bad/corrupted vmlinuz (its CRC32 is checked before the "big jump").
- Gujin is nearly completely written in C, so easily modifiable/extendable: it does few things differently considering the version of Linux loaded...
- You can boot in graphic all the time, even with a old PC with only a VESA1 or VGA-only video card (CGA/EGA works also on my test system). The video mode used by the kernel is easier to select.
- Most of the subsystems are written using BIOS _or_ direct hardware access, so it will work if it is either BIOS compatible or hardware compatible.
- Gujin runs in i386 real mode and so is compatible with PC BIOSes generating special interrupts (power saving initialisation...) during the boot loading process.
- The mouse (PS2 or 3 types of serial mouse on COM1..COM4) is detected at the right time and used. This info is passed to the kernel.
- You are fed up executing linux/arch/i386/boot/{bootsect.s,setup.s,video.s}
- You want to build a floppy distribution, with max 30Kb of bootloader and an easy way to change the kernel/initrd.

If your aim is to install Gujin on your floppy and/or hard disk, first download install.tgz and extract it in a directory. Then start by reading install.txt.
You can come back to this FAQ if you have a problem.
You can also use the Ultimate Bootable CDROM:

Note: If you are using MS-Windows XP to download Gujin files from sourceforge, you may notice that downloaded filenames change on the way to your PC: the "tgz" extension is changed to "gz" without any reason. Double check the name of the files you have downloaded before opening them - rename if needed.

Note: DO NOT play with the floppy under Win98 (and maybe other versions) when you are in DOS mode (i.e. start->shutdown->reboot in DOS mode, not in a DOS window). There is one way to physically break a floppy driver, just ask a cylinder higher than 80 and you immediately hear the "sound of death".
My drivers (in Gujin) will never ask a too high cylinder on a floppy, but the drivers of Windows in a DOS environment do that quite easily. It has cost me two floppy drivers (one to detect, one to check) in 5 minutes, and I was not even using Gujin... You can still safely copy (drag & drop) files under the graphic interface and then reboot to DOS mode.

• Download the file "standard-0.9.tgz", un-tar it "mkdir standard; cd standard; tar -xzf ../standard-0.9.tgz" or open it with winzip or winrar if you have another operating system.
• Select the image/executable you want to try: begin with "full.img.gz"/"full.exe", you can play with others later.
• Insert a clean 1.44Mb floppy on your drive, the data on this floppy will be erased (no bad sectors).
• Do "zcat full.img.gz> /dev/fd0", or if you do not have "zcat", type "gunzip -c full.img.gz> /dev/fd0"
  If you have an error accessing the drive and are using automount/supermount, try "umount /mnt/floppy" before retrying the zcat.
  If you are using another OS, try "rawrite.exe" (after decompressing "full.img.gz" to "floppy.144" again using winzip/winrar), see: http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm.
  If you do not like previous software, you can also try: floppyimage.
• If you have DOS/Windows (excluding NT), you can now copy "full.exe" on the floppy, for instance "mcopy full.exe a:"
• Reboot your computer keeping the floppy in place, you can after a short time play with the mouse.
• If you have a DOS installation, boot its Master Boot Record to play with "A:\full.exe".
• The other files you get in "standard.tgz" are described in this FAQ question.
• If your version of DOSEMU / Xdos is not too old, you may try "zcat full.img.gz> /var/lib/dosemu/floppyimage" and then "dos -A 2>/dev/null" or "xdos -A".
  Remember to have enough XMS memory ($_xms = (4096)) to load the vmlinuz file when executing "boot.exe".
  See also "/etc/dosemu.conf" ($_vbootfloppy="floppyimage +hd") and "/etc/mtools.conf" (drive o: file="/var/lib/dosemu/floppyimage").
You can also use Gujin to debug "Bochs" (full.img being the virtual floppy), "Plex86" or "VMware"... if you want to.

Note:
• All the images (*.img) are for 1.44 Mb floppies, use the "instboot" executable for other formats.
• All the images contains the FAT and root directory: the executable size is not as big as the file size.
• The floppy used should not have "bad sectors".
• For most configurations, there is two independent files: the image (*.img) to be copied to the floppy in raw format (do _not_ use the DOS command "copy" nor drag and drop for this one !), and the standard DOS executable file (*.exe) which is a standard file to be copied the way you want, but needs at least DOS to run.

Once decompressed, the file "standard.tgz" contains:
• full.img.gz / full.exe : that is the complete configuration, the one I tested the most; you probably do not need all that (mostly the serial interface).
• french.img.gz / french.exe : same as "full.img.gz / full.exe" but the messages are in French.
• medium.img.gz / medium.exe : same as "full.img.gz / full.exe" but the support for the "mini-debug", the serial (VT420) support, and the analysis of the I/O ports used by the video card are removed.
• small.img.gz / small.exe : same as "medium.img.gz / medium.exe" but the mouse support, the support of 4 BPP (16 color) graphic and 24 bit VESA modes, the VESA_HARDWINDOW analysis which cannot be used right now by Linux, the support for the VGA only cards, and the verbose messages are removed.
  Note that even some 486 refuse to boot if the video card is not VESA 1.0+ compliant, so it should be quite safe to remove the VGA support.
• tiny.img.gz : the smallest possible (keeping vmlinuz/initrd compatibility), just add "vmlinuz-2.4.16" and "initrd" on the FAT12 floppy (boots the first kernel loaded successfully, Gzip comment fully checked).
• tiny.exe : the smallest possible DOS loader, do not probe disks nor video modes, use it as loadlin.exe: "tiny.exe c:\dir1\dir2\vmlinuz c:\dir3\initrd.gz opt1=val1 opt2=val2".
There is also these few DEBUG setup: They put information on a DOS file to be useable by everybody.
Just create a DOS bootable floppy ("format /s a:" under DOS, preferably DOS6.2 - or a rescue boot floppy from Win9*/WinMe) and copy the executable to this floppy.
Then, you boot out of this floppy and execute the file.
It will do the same as the bootloader but also create a file named "\DBG" (stay in "A:\") to store a lot of information.
If you have a problem with Gujin, I need this DBG file to debug!
Note that you need to either exit Gujin (^C or ^D will do) or run a kernel to flush and close the file properly: do not reboot.
There is different executable (very few are here) because of size restrictions, and readability of the DBG file.
Advise: do not play too much with these files under DOSEMU, I already crashed few virtual disks...
• dbgvideo.exe : to debug the video (VGA and VESA) subsystem.
• dbgdisk.exe : to debug the disk (BIOS, EBIOS and IDE) subsystem.
• dbgload.exe : to show which parameters are passed to Linux, and some A20 debugging.
• dbgfs.exe : to show the process of selecting files on each filesystem...

• Download gujin-0.9.tar.gz and read the (beginning of) file "Makefile"; you will be able to comment/uncomment lines to select your own configuration (support of VESA, of EDID, of serial terminal like VT420, language...).
  It is better to have GCC-2.95.4 or newer (GCC-3.4.2), egcs-2.96.* early versions (RH 7.0 and Mandrake 8.0) _do_ _not_ _work_ (because of -fstrict-aliasing), egcs-2.91.* could work, gcc-2.7.* will not.
  It is necessary to have binutils-2.9.5.0.33.tar.gz or better ("make" will check that), I use GCC-3.4.2 and binutils-2.15 bootstrapped manually by "make toolchain". (binutils-2.12 and binutils-2.12-1 have a small problem and Gujin will not link).
• create a directory structure like this:
projet/
projet/gujin-0.9.tar.gz
projet/binutils-*.tar.gz (if you want to rebuild it)
projet/gcc-*.tar.gz (better gcc-core-*.tar.bz2 if you want to rebuild it)
• Go in "projet" directory and type "tar -xzf gujin-0.9.tar.gz" which creates the "projet/gujin" directory, go in it.
• Type "make" without parameter, this recreate dependencies, file "code16.h", and show you some possible parameters.
• If you want to rebuild the compiler and/or the assembler and linker (binutils), type "make toolchain" and have a cup of coffee.
  You do _not_ need to be root for this - and it will _not_ install the compiler/binutils as default, just locally.
  Note that when "make" is called without parameters, it displays the version of compiler and binutils which will be used.
• Now, you can (as "make" says you), type things like: "make /dev/fd0" or "make boot.exe" or "make tiny_exe" or "make /dev/fd0.com1"...
  and you can then reboot your computer.
• You can also type "make standard.tgz" or "make install.tgz" to re-produce the precompiled file.
• Build and use the "gzcopy" command (by "make gzcopy") to specify special command line parameters for *.kgz files. It is also possible to add the gzcopy to Linux Makefiles at the right place.

Check that you have selected "floppy before hard drive" in the boot order in your BIOS set-up.

Note: There could be another reason to just see one copyright line and then a quick boot: if Gujin is configured with autoboot after timeout on the only bootable system detected and verbose mode OFF and writing to disk disabled, it will decide to skip its menu and video initialisation and immediately boot the only detected system.
It will still quickboot if exactly two bootable system are detected, but they are the same (partition/filesize/inode) on two disks with different access method (usually EBIOS and IDE) so that SMART status can be checked, and the first (EBIOS) will be loaded.
This way, if you have only one partition (for instance FAT32 or NTFS) without any kernel file, you will "quickly" boot it.
You still have Gujin checking partition overlap, disk with bad SMART status display when a major problem appear - but nothing else up to the time you install a serious operating system... or you install another hard drive with another version of your initial operating system, or you boot with CAPS-LOCK active.
The installer has the option "--quickboot=<number of second>" as a shortcut to initialising the "timeout autoload", verbose to OFF, disable disk writing, probe only partition's MBR on the BIOS and standard IDE hard disk, and have a default video mode number 3 (simple text) if the screen is not EDID.

You are probaby using an USB keyboard and/or mouse, i.e. the keyboard/mouse plug you are using is a rectangular plug and not a round plug. You have to enable, in the BIOS screen (at boot), the BIOS emulation of keyboard and mouse (sometimes called DOS emulation).
Alternatively, you can use a serial mouse (large rectangular plug in COM port on the back of the PC).

Check the partition type using fdisk: it has to be 0x83 for a Linux partition, right now Gujin only recognizes E2FS and E3FS.
Some installer (at least you can get this problem with RH7.2) forget to set this byte and leave the DOS FAT marker.
Linux does not care about the partition marker, and will work without problem with any value (because it uses /etc/fstab to know the kind of filesystem), but Gujin need this information to be correct.

It is possible not to switch to text mode when starting a kernel, this is a configuration option, in the config screen menu.
The problem is that Gujin can not (right now) detect if the kernel can/need to start in text or in graphic mode (VESA framebuffer compiled in or not, and which number of BPP are supported). Note that this is not related to compiling a videocard framebuffer as static (and not as module) where a new mode is set when the chipset is initialised.
To start in graphic, follow these steps:
First check that your kernel is compiled with VESA framebuffer support, supporting _all_ the BitPerPixel you can switch to on the Gujin interface.
If you are using 2.6 kernels, check that "Framebuffer Console support" is set in "Graphics support->Console display driver support" (make menuconfig).
Now double check that your video board is VESA 2 compilant, Linux cannot handle right now the memory window switching of VESA 1 boards, unlike Gujin. Gujin displays at startup the VESA level of your video card.
Then (and only then) you can uncheck the "force last text mode at startup" option in the setup screen.
Note that most older standard kernels in Linux distributions are not compiled with framebuffer support, or only with 4 BPP support, so use this option with care.
Note also that some distribution default kernel can _only_ start in graphic mode (some Mandrake start correctly only in 8 BPP modes). RH7.2 start in text and in graphic.
This feature is a hack - later I would like to put all this kind of kernel description in the "comment" field of the gzip file.

No, Gujin is not only a boot loader but also a Linux system loader; for instance you can load system files (vmlinuz) of unlimited size (well, below the size of your physical memory), and so do not really need to use modules even when your kernel is very big.
You can also run another loader (i.e. LILO or the FreeBSD loader or the DOS/Win95/Win98/WinNT loader) from Gujin.
The source code is not derived from any other bootloader, that is a complete rewrite, from scratch (memcpy(), printf(), malloc() ... are all rewritten).
Note that there is different LILO versions named (boot sector at offset 3) slightly differently: LILO, zLILO, lbaLILO and oldLILO.

On a usual PC, the Hard Drives are IDE (not SCSI) and are detected using the BIOS interface _and_ using the IDE interface.
Because the BIOS interface may not access the total content of the drive (buggy or too old) - you can use the IDE interface; and because there may be some trick on your partition table (a small software intercepting INT13) which will break IDE interface you can use the BIOS interface.
You can select what to probe in the setup screen, this will be saved on the boot medium (if not write protected).
Note: Some BIOS leave empty space on the hard disk depending on the number of heads and the number of sector per track selected for this drive. This probably happens on very old BIOSes and with non LBA compatible hard drives (kind of 220 Mbytes hard drives). Then, Gujin IDE interface may not work correctly - I do not have such a hardware to check.

I do not like configuration files, there is none.
Moreover, when a PC has two or three distributions installed, where should Gujin look for this configuration file? In which root filesystem?
So you can use the same floppy disk to boot any PC you want.
Note that (very) few information are stored in the beginning of file BOOTxxx.SYS, like the preferred text and graphic video modes. On another PC, this video mode may be invalid - so you can force the video mode at beginning (when the first line is being displayed) by pressing "Control"; a message saying "video mode set to simple text" will be displayed.
To erase all information stored on the floppy, like the setup selection, press CAPS-LOCK before the first line has been completely printed.
Do not try to modify the file BOOTxxx.SYS or to rewrite it: the complete boot process is protected by checksums.

Gujin sometimes need to know which keyboard language/mapping you are using, to correctly interpret the keys you type, for instance when setting the kernel command line or asking for a password.
Gujin may ask you automatically, or you can ask it in the setup screen (near the end), it is simply done by pressing few determinant keys - and it is saved if disk can be written.
Basically, Gujin recognise those keyboards:

• us: the United State keyboard.
• uk: the United Kingdom keyboard.
• ca: the Canadian keyboard.
• br: the Brasil/Latin America keyboard.
• no: the Norway keyboard.
• fi: the Finland/Sweden keyboard.
• dk: the Denmark keyboard.
• nl: the Netherlands keyboard.
• sp: the Spain keyboard.
• pt: the Portugal keyboard.
• it: the Italy keyboard.
• qwerty: none of the above recognised, but still a qwerty keyboard.
• fr: the French keyboard.
• be: the Belgium keyboard.
• azerty: none of the above recognised, but still an azerty keyboard.
• de: the German keyboard.
• ch: the Switzerland keyboard.
• qwertz: none of the above recognised, but still a qwertz keyboard.

Note that I have used a book on some keyboards, so if you find an error or if your keyboard is in this list but is just recognised as a qwerty/azerty/qwertz keyboard, please send me corrections.
To check, just press each key (with and without shift and alt) while entering a dummy kernel command line. Really take care of all accents and small signs because they look the same in a book.
Note also that Gujin display only ANSI characters, so the Euro key cannot be displayed. When "verbose" is active and you are in the standard menu, it shall produce a key error with keycode 0x0, saying the key has been recognised. The book was older than the euro, so the Euro key is a guess most of the times...
Keyboards layout dvorak and dvorak_ansi can be enabled by the INCLUDE_DVORAK_KEYBOARD compile option - but I am not sure anybody uses that anymore (they cannot generate ^W and some other control and some alternate letters).

Yes, but you need to recompile. Moreover Gujin assumes the font is an ANSI one, i.e. not the very old PC mapping with accented letters in between 0x80..0xA0, so that the file "messages.h" can be easily edited on an up to date operating system (not only bare DOS).
Gujin is designed to handle only fixed font size, with at least 8x8, 8x14 and 8x16 resolution for text modes. The graphic system (VESA graphic) can probably handle bigger definitions without modification but that has not been really tested.
If you want to try, a good starting point is to search on Internet the file 2l8fe122.zip which is a DOS font editor and fntcol16.zip which is a collection of DOS fonts (read included file copyleft.txt).
You will need to modify the font files to include accented letters at the right place.
Gujin uses font file in C source with an array like (see font.c):
['8'] = {
B (_,_,_,_,_,_,_,_),
B (_,_,_,_,_,_,_,_),
B (_,X,X,X,X,X,_,_),
B (X,X,X,X,X,X,X,_),
B (X,X,_,_,_,X,X,_),
B (X,X,_,_,_,X,X,_),
B (_,X,X,X,X,X,_,_),
B (_,X,X,X,X,X,_,_),
B (X,X,_,_,_,X,X,_),
B (X,X,_,_,_,X,X,_),
B (X,X,X,X,X,X,X,_),
B (_,X,X,X,X,X,_,_),
B (_,_,_,_,_,_,_,_),
B (_,_,_,_,_,_,_,_),
},
and the makefile can convert in between this format and binary format using a simple objcopy, or for the reverse operation the source file fntbin2h.c compiled to ./fntbin2h.
If you type "make font8x16.h" having file "font8x16.bin" in the directory with the correct size (no header, no trailer, 8 bit wide font 16 bit high so 16 bytes per letter and 256 letters so 4096 bytes - most fixed font editor use this format to store and retreive fonts) you will get "font8x16.h". You can then regenerate "font.c" with cut & paste of the three files "font8x8.h", "font8x14.h", "font8x16.h". You can get the current font Gujin is using by "make font8x8.bin", "make font8x14.bin" and "make font8x16.bin"
The order of the letters in the include file reflects the ANSI mapping (letter "e" with all its form are grouped together) and the initialisation using the "['achar']" GCC extension enable to check quickly the right shape is used for the right letter.
The font is stored in the extra data segment in Gujin executable so there is no space problems.

360K, 1.2M, 720K, 1.44M, 2.88M (last untested but simulated on CD)
1.68 Mbytes floppies are supported if your BIOS is able to read sectors over 18 on a floppy, your BIOS do not need to be able to read more than 18 sectors.
Note that you can type under Linux (when mtools installed):
"mdir -a a:" and you will see the hidden file "BOOTxxx.SYS" where xxx will be 144 for a 1.44 Mb floppy.
There is no problem to add files to this floppy, that is a real MSDOS FAT12 partition.
To save space, you can reduce the number of root directory sector (total number of files/directories in root if using 8+3 filenames, 512/32=16 8+3 names per sectors, less if using longer filenames), increase the number of sector per cluster, and/or reduce the number of FAT.
Reducing the number of FAT (from 2 to 1) decrease the compatibility, DOS is no more able to read the floppy, but mtools works perfectly.
Try: ./instboot --fs=FAT:2880,4,1,1,1 boot.bin /dev/fd0
New: How to create a floppy (or whatever FAT12/16) with 1024 bytes per sector instead of 512 bytes? This simply works on a 1.44 Mb floppy:


$ ./instboot boot.bin /dev/fd0 --geometry=1440,0,2,9,1024 --disk=BIOS:0x0 -w
$ mount -t vfat /dev/fd0 /mnt/floppy/ -o blocksize=1024
$ ls -l /mnt/floppy/
total 144
-r-xr-xr-x    1 root     root       147456 Mar 15  1999 boot-bio.sys
$ mdir -a a:
 Volume in drive A is EL-BOOT-V09
 Volume Serial Number is 3939-4C45
Directory for A:/
BOOT-BIO SYS    147456 1999-03-15  12:34
 1 file              147 456 bytes
 1 310 720 bytes free

I have reduced the number of sectors from 2880 to 1440 and the sector/track from 18 to 9 because the sectors are twice the size, normally the '-g' option is "--geometry=2880,0,2,18,512" for 1.44 Mb floppies.
Which values are valid for sector size? I do not really know, 2048 and 4096 should work (I think Gujin limit it to 64 Kb) but try it yourself.
Do not hope to be able to read this large sector floppy in anything else than Linux: even the BIOS will load only the first 512 bytes on such a floppy, so Gujin cannot boot from it (initial checksum error of Gujin2).
Smaller sector size (256 or 128 bytes) will not work because Gujin1 is not entirely loaded so cannot load Gujin2.

Gujin is a GPL software, so without guaranties of any kind, but because it is not writing to the hard drives until the user enables it, the risk is very small.

Gujin is looking for all files named "vmlinuz*", "zImage*", "bzImage*" or "*.kgz" in every E2/3FS or FAT12/16/32 partitions, either in the root directory or in a subdirectory named exactly (but case insensitive) "boot" - to show you a menu where you can click.
Gujin also looks for all the Master Boot Sector (first sector of the disks) which have at least one primary partition with the "bootable" flag, and for all Partition Boot Sector (first sector of each partition) if they seem to contain boot code (if it is a FAT partition, you need a file named IO.SYS/IBMBIO.COM in the root directory if not "keep all partition's mbr") to add to the menu.
So, you can power-up a PC with a fresh Linux installation on a new hard disk, and directly run it.

Note: The Master Boot Record will always appear, even if none of its partition are marked "active", to not change the number of bootable systems and to not confuse the autoboot feature. In this case, booting this Master Boot Record will probably display an error.
Booting Linux will not modify any hidden/visible partition nor any "active" partition.

Yes, it will load the file "initrd*" if it exist in the same disk, partition and directory as the file "vmlinuz*"/"bzImage*"/"zImage*" selected.
If there is more than one "initrd*", the file with the nearest ending as "vmlinuz*"/"bzImage*"/"zImage*" will be loaded, nearest ending means either the ending is identical, or the number of identical char at the end of the filename is bigger.
For instance, if you are clicking on file "/boot/vmlinuz-2.4.0" and there is two files in "/boot" named "initrd-2.gz" and "initrd-2.4.gz", the later is loaded, the number of char matching being 4: "-2.4".
As an extension, if the initrd file is named "initrd.img-2.4.18", the part ".img" is ignored in the comparison.
You can decide of a minimum number of identical ending char to associate an initrd to a kernel, on the setup screen or with the instboot option "--min_nb_initrd="; if this minimum is not achieved, the initrd file will not be loaded - but if the ending is strictly identical. If this value is more than 9 chars included, the initrd loading is completely disabled. The initrd file has to be a GZIP compressed file, i.e. with the first two bytes "0x8B1F" (to check its CRC32).

By default, the kernel file (vmlinuz-2.*.xx) contains the root partition to mount first as "/" - it is set to the current root of the machine compiling the kernel.
On most distribution (if you are using the distribution default kernel), this is a SCSI hard drive, like /dev/sda3 - and LILO will change it depending on "/etc/lilo.conf".
This default root can be seen by "rdev /boot/vmlinuz", and can be set by (for instance) "rdev /boot/vmlinuz /dev/hda2".
If the default root of a vmlinuz file is zero - or is a SCSI disk on a PC which has no SCSI disk - or when the root detection is forced in the setup screen, then Gujin tries to find a valid root partition:
If the "vmlinuz" file is in a "/boot" directory and the filesystem is E2FS, the root is the current partition; else Gujin looks for a directory which contains a subdirectory "/boot" in each Linux-type partition (0x83, usually ext2 or ext3) first on current HD then on all HD - then it declares it as the root partition.

Note: Now, at least RedHat 7.2 has switch to an IDE machine to produce its default distribution kernels, hence the addition of the "force root detection" option.
Note: there is another and different message which will appear on some distributions, later in the boot process (at root filesystem ext2/3 checking) when the root partition passed to the kernel is not the one described in /etc/fstab. If you have such a problem, first check that you did not check the "keep BIOS disk order" in the setup screen. If you have a strange IDE order, you can setup the "ide[0-9]=0x" options on the command line, that will disable autodetection/autoorder of IDE interface (but keep the "root=" autodetection unless you write it manually) - take care "ide*=0x" hexadecimal numbers have to be in lower case. Another solution is to boot another Linux and change /etc/fstab manually - until the distribution implement better startup files. You could also try (dangerous) to mount the root filesystem in read/write mode (kernel command line).

Because Gujin will not try to guess the relationship between a BIOS drive (0x80, 0x81...) and an IDE drive (IDE at I/O 0x1F0, 0x170, 0x1E8...).
For new PCs a BIOS field describes on which IDE the BIOS drive is, but not on 386/486 BIOSes.

Some BIOS on newer motherboards are able to detect that there isn't any bootable partitions on the master drive of the first IDE interface, and the slave drive of the first IDE interface has a bootable partition. They are then able to swap BIOS drives 0x80 and 0x81 to keep a bootable disk on disk number 0x80.
Well I cannot really help you there, but there should not be any problem if you just have one Win* setup, because booting Linux does not hide/unhide partitions.
Note that when you boot from a floppy disk, you have the real order of drives.

When you type "make boot.exe" (or "make boot.com" if the file is smaller than 64 Kbytes), you get an MSDOS executable which is able to load a vmlinuz and an initrd file.
Note that in DOSEMU and WinNT/whatever they call that now, the kernel file is loaded correctly but the DOS emulator stops the execution of Gujin when it tries to switch to protected mode, and that cannot be "corrected"!
In the default configuration (no BIG_MALLOC and text or VESA1 video modes), the executable is 100% compatible with MSDOS, and so the "subst.exe", network redirector software and DOS USB device drivers should work.
If you do not want the graphical interface, you can use "tiny.exe": it is as simple as:
tiny A:\boot\kernel A:\boot\initrd root=/dev/hda3 ...other cmdline params...
or without initrd (note the minus sign):
tiny C:\kernel - root=/dev/hda3 ...other cmdline params...
You can even run that with EMM386 and a disk cache loaded on DOS, but it will not autodetect the root filesystem alone because it does not probe any disk.
Note that if HIMEM is loaded its interface is used (DOS in high memory works), but you shall have enought HIMEM memory to load the kernel and its initrd in the same XMS block (else you get error message: "error 0x229B loading file").
If HIMEM is not loaded then the BIOS INT 0x15/0x87 is generally used (see function treat_data() of gzlib.c).
Win* (excluding XP) boot floppies seem to work perfectly with boot.exe/tiny.exe, but my reference is still MSDOS 6.2.
Note also that you cannot use wildcards on the kernel/initrd names, and you must execute it either in text modes or in VESA2 modes (i.e. graphic VGA modes are a no no!) mostly because tiny.exe is just 30 Kbytes!

Well, because I do not see a solution to plug-in a debugger, at least at an acceptable price, you can use the built-in logger, by defining the DEBUG variable in Makefile to send log messages to a serial or parallel (printer) port, or to a DOS file (if boot.exe), or to the screen, to know where exactly is the problem.
The DOS file method is easier but cannot handle complete crash because of the buffering, and you have to close the file cleanly by exiting Gujin (^C or ^D will do) - use a serial line in extreme cases.
Note also that IDE probing is completely disabled under DOS/Windows because it is a bad idea to access directly the IDE under an operating system, but if you are running dbgdisk.exe or dbgfs.exe - you can re-enable them on the setup screen even if they are greyed. It is a very bad idea to do it on something else than the bare DOS.
Note that to read the bootsectors (Master Boot Record or Partition Boot Record) you can use 'hexdump /dev/hda | less' or 'hexdump /dev/hdb1 | less'
You can get their assembly by doing:
dd if=/dev/hdb of=copy_hdb bs=512 count=1
objdump -D -m i8086 -b binary copy_hdb | less
objdump -D -m i8086 -b binary --start-address=0x3E copy_hdb | less

Well, it is up to you to say! I still have to write some new features, but there are probably still some bugs I am not aware of...
To write this software I had to re-write nearly everything, up to the memory and string management functions (malloc, memcpy, strlen, printf...), the GZIP decompression functions and the FAT12/16/32 and E2FS (read only) functions.
I really welcome success story, bug report (or better patches) at:
etienne.lorrain@masroudeau.com
If you have compiled yourself the code, please check before reporting a bug that it is still present after a "make proper dep /dev/fd0".

It defines the way the video memory is accessed:

[VGA] : all characters are displayed using _only_ VGA BIOS functions
[INT] : in VESA modes, use the interrupt to change graphic window
[FCT] : in VESA modes, use the function to change graphic window
[hard] : My recorder works - access I/O ports to change graphic window
[hardc] : Same as [hard] but array is compressed (VESA 1.* default)
[lin] : Linear window used in real mode (VESA 2+ default)
[nowin] : The complete video memory fit in 64 Kbytes (VESA 1 or 2+)

There could be two [hardc][hardc] to say that a separate read window and a write window are used.
It is abnormal to have something else than [lin] on VESA 2 or VESA 3 cards - but maybe for 16 color modes, under some memory managers, or when VESA2 support is removed from the configuration in the setup screen or in the Makefile.

First, you probably need them only if you want a video mode which has not been detected at startup. Gujin should detect (and manage) all VESA video modes with more than 4 Bits Per Pixel and with an identification number higher than 0x100.
If you have a VESA video card, and you know it supports some video modes which are not detected at startup (usually you would like some extended text modes), then ask to "probe VESA modes 0..0x7F" first. This check is safe and fast.
If Gujin has write access to the disks, it will save the current video mode, and use it at next startup; that is working without any problem for VESA mode below 0x100. The total number of video mode available is written on the first line of the screen.
If you do not have a VESA compatible video card (VGA only, look at messages when Gujin starts) or the previous VESA probing did not give you the mode you are looking for, you can probe VGA video modes.

Note: Because it is not possible to get information about a VGA mode without switching to it, this probing is slower and a bit less safe. If you have a correctly written video BIOS, when asking it to switch to a mode it does not support, it should either not switch to this mode, execute an invalid instruction, execute a division by 0, or do an infinite loop. All of these cases are correctly handled by Gujin. The only thing it should not do is an infinite loop when interrupts are disabled, because then the timeout manager cannot execute the timeout...
Because the later case may happen, and if the disks are in read/write mode, a tag is written on the disk before trying to switch to each mode. If you have to do a manual reset, then this VGA video mode is saved as "unusable". You can then, when you get back Gujin interface, restart the VGA probing - this mode will be skipped. Note that writing to the disk twice per VGA mode test is slower, mostly if Gujin is on a floppy disk.

To probe for VGA mode, you should first test the standard ones, from 0 to 0x13.
This is probably working without problem on all PCs. Then you can stop here if you have found the mode you were looking for. If you switch to one of these video modes and disks are read/write, the default video mode is saved and you will get this mode at next startup.

Note: The video modes known from the VESA interface (by the first probing) are not re-probed in the VGA interface, that why the order is important. The VESA driver of Gujin do not manage video modes below 4 BPP (i.e. less than 16 colors), the VGA driver will detect them.
Finally, if you want to do an extensive probing of you VGA interface - for instance because your video card is "SuperVGA" and supports mode like 1024x768 in 256 colors but has no VESA interface - like some Compaq P120 systems, you can run the probing of VGA mode between 0x14 and 0x7F.
You should then have all the modes you video card is able to do.
Gujin will propose you to turn OFF your screen until the end bip because some (very old?) monitor can have problems with the too high refresh frequency that the BIOS may produce in some video modes - even if it stay in this mode just long enough to get its characteristics.
Note: The list of "unusable" VGA video mode, the basic characteristics of "usable" VGA modes and the default video mode (default text and graphic) are saved in between boots in the "boot*.sys" file. These parameter are reseted if the video card has physically been changed (detected by the change of the card name of the VESA interface) or manually by pressing Caps-Lock before booting Gujin. If you physically exchange VGA-only video cards in your PC, it is up to you to press Caps-Lock at next reboot.
Also, the default video mode being stored, you do not need to have the screen powered ON to start Gujin (the EDID is not re-checked). But it is a lot safer to restart Gujin with Caps-Lock active if you have physically downgraded the screen.
Note: It is better to "reset VGA/VESA modes 0..0x7F" in a VESA mode, or switch back to VESA (and re-switch to VGA if you want) after this command, or simply restart the computer. If not, the invalid modes disabled in VGA initialisation are no more disabled (because VGA initialisation is not done) and you will test for instance mode 0x8..0xC at next VGA video mode probing. It still can be useful when you know what you do, so I keep it.

It is probably with hard disks using BIOS or EBIOS interface.
It means your BIOS cannot access the entire content of this disk. If the access is using BIOS, your hard disk has probably over 1024 sectors; if access uses EBIOS, your Extended BIOS may not be able to access more than 8 Gbytes.
In the later case, double-check the BIOS set-up: the autodetect feature of your BIOS (accessed at boot time) may not detect more than 16383 cylinders.
Try to set manually the cylinder field correctly. If you cannot, use only the IDE interface on this drive.
This message also appear when your [E]BIOS is reporting a size a bit smaller than the real disk size, and you have created the last partition under Linux:
The [E]BIOS will probably not be able to read a file if it is mapped in the last few Mbytes of the drive - but that is not usually a problem.
Note: The [E]BIOS may decide to report one sector less to the operating system because it is using this last sector for test purposes, at boot time. Then, it is really unsafe to store anything in this sector, because it may be written at each/some boot - so this sector shall not be mapped in a partition. Also some EBIOS no more support the indianess problem on the disk size of very old drives (< 512 Mb), and that can produce such a message.

Gujin will detect extra IDE ports if they are at standard addresses (0x1F0, 0x170, 0x1E8, 0x168, 0x1E0, 0x160) and/or if that address is reported by EBIOS. The PCMCIA IDEs are not handled (I do not have such a hardware). USB disks are not IDE so not handled, I may also try one day to manage the disk slot of some CDROM drives.
I just have a HTP372 RAID controller, so Gujin is tested on this hardware.
Usually, those extra hardware are hem... less compatible ... than standard IDEs. I just had to handle those features on my board:

• HTP BIOS do not handle ATA1 disks, where the IDE size reported is zero, you just need to multiply head*cyl*sect to know its size (HTP size is -1).
• HTP BIOS do not handle ATA2 disks, where the size reported has a strange half indianess, and they remove 65536 sectors instead of 1.
• HTP BIOS does not report the size of the disk on INT 0x13/ax=0x1500
• HTP BIOS crash - at least interrupt disabled or worse - when you try to reset disks after requesting PIO data with IDE interrupt disabled.
• HTP BIOS do not initialise nIEN of the IDE control register before performing a read or a write to the disks.
• HTP BIOS report _one_ sector less than the real disk size on extended BIOS call, so you can get the message "EBIOS: disk ... last partition over disk limit detected (0 Kb)!". The 0 Kb is because there is 512 bytes (1/2 Kb) lost if the disk has been formatted on Linux and fills completely the disk...

If your hardware/BIOS has more bugs than that, Gujin will not work, you may still try to disable either the IDE or the BIOS interface.
Some PCI said-IDE extender do not implement the ALTSTATUS register (always reads zero), Gujin cannot work on that IDE incompatible stuff.

This hasn't anything to do with Linux parameters.
This has to be checked at all time, but when you intend to use trusted kernel files (*.kgz) to setup IDE passwords/configuration or IDE aware partition tables manager.
In short, newer hard disk may have a password protection system, that is a very high protection system - transforming a hard drive in a real brick if you forget the password.
You should never enable this password protection system if the data you store on the hard drive does not worth AT LEAST few times the price you paid for the disk.
If Gujin find at boot a hard disk protected by password, it will ask you this password (it needs the layout of the keyboard, so may ask you to type few keys before, see also the read only mode of Gujin).
Gujin just handle the standard ASCII characters, i.e. from ' ' to '~', for the password (no accented letters).
I need to say that: GUJIN IS A GPL SOFTWARE WITHOUT WARRANTY OF ANY KIND, THERE MAY BE A BUG SOMEWHERE, IN GUJIN OR IN YOUR HARD DRIVE OR IN THE IDE INTERFACE, WHICH TRANSFORM YOUR HARD DISK TO A BRICK, I AM NOT RESPONSIBLE.
And also: I DO NOT STORE THE PASSWORD YOU TYPE ANYWHERE, DO NOT EVEN E-MAIL ME IF YOU HAVE FORGOTTEN YOUR PASSWORD - I DO NOT CARE.
EVEN YOUR COMPUTER SUPPORT HELPDESK CANNOT KNOW THIS PASSWORD.
And logically: DO NOT PROTECT BY PASSWORD THE BOOT DISK IF YOU WANT TO LOAD GUJIN FROM THIS HARD DRIVE, you will only be able to boot from a Gujin floppy then.
I have tested it with my SEAGATE and WESTERN DIGITAL hard drive, it may work for you. IBM drives seem to work also (not fully tested, it is a production machine...)
The problem of those drive appear when you are running an unsafe operating system, a virus may activate the password system with a random password...
So gujin will by default freeze passwords on drives having this capability, freeze their configuration and set a maximum LBA, so that nothing will be able to modify the password subsystem until the next power off.
It will do so before running any operating system, even Linux, a MBR based loader or even Gujin itself (Gujin can load Gujin), if this box is checked.
If the box is unchecked, it will rely on the "option" GZIP comment of the *.kgz file.

Gpl Use of the Jnp INstruction.
I do not think anybody has used this 80x86 assembly instruction (jump if no parity) during the last 10 years, mostly for a GPL software. It saved me a byte in the boot sector - and there is only 0x1B6-0x3E = 376 bytes available there to do a lot of things, even if you have, on your PC, multi-gigabytes of RAM and few hundred of gigabytes of Hard Drives!

Well, try another floppy disk. Also there is sometime quite a lot of dust in the floppy driver... but that is a cheap device.
If you want to check, you can boot Linux and type:

cat /dev/fd0> /dev/null

You will probably get something like:

floppy0: data CRC error: track 2, head 0, sector 17, size 2
floppy0: data CRC error: track 2, head 0, sector 17, size 2
cat: /dev/fd0: input/output error

First, you need a twisted serial cable.
Install Gujin on a floppy with "make dep /dev/fd0.com1" or "./instboot boot.bin /dev/fd0 --serial=com1,9600,n,8,1".
Start "minicom" on the second PC running Linux and configure it to 9600 bauds (the BIOS maximum) on the port you plugged the serial cable.
Power up the PC with the Gujin floppy.
If you want to, you can use the mouse - but only the one of the Gujin's PC!
Note also that message concerning the modem at the beginning: if you set up an ATDT sequence, you can remote boot through a modem (distant computer).

There is a test in "linux/arch/i386/boot/tools/build.c" to abort the generation of a kernel bigger than 2.5 MB uncompressed, because those kernel cannot be loaded by LILO.
If (and only if) you have a 2.4.1 or later kernel, it does not matter: you will still have in the top Linux directory the file "vmlinux".
Type:

objcopy -O binary -R .note -R .comment -S /usr/src/linux/vmlinux linux-2.5.1
gzip -9 linux-2.5.4
mv linux-2.5.4.gz linux-2.5.4.kgz
Then copy this "linux-2.5.4.kgz" to "/boot" and reboot.
If you want to boot a 2.2 kernel, you will have to remove the test in "build.c".

Note first that only BIOS compatible joystick will work, they should work if they are detected at startup (in between number of serial ports and type of mouse).
Note: Most of the newest joystick (who have more buttons to press than fingers you have) are not BIOS compatible - joystick manufacturer do not believe hardware compatibility is important. Maybe one day the USB Joystick will be managed by the BIOS, like USB keyboard and USB mouse.

You should uncheck it only if those two are true:
• if you are sure that the default root coded in file vmlinuz is valid (i.e. you have compiled the kernel yourself and you will use it with the current filesystem, or you have set it up manually with rdev)
• Gujin is not able to find alone the root filesystem (You have different distribution of Linux and all the kernel are in the same "/boot/" directory; or the root partition is a FAT filesystem).
Setting manually a "root=" parameter on the command line will still override this option, whether it is on the Gujin "extra command line" or in the comment field of the GZIP file.
History: Before, it was possible to detect that a distribution default kernel was booted because its root was on a SCSI drive, and the user's PC did not usually have an SCSI interface.
Now, some distribution (RH7.2 at least) are using IDE only machines - and so the default root coded in file vmlinuz seems valid, but is not on your own machine.
It is a hack, standard distribution should reset this "root" parameter to zero to show that they do not have a clue of the root filesystem of the user's PC; but rdev do not allow to enter such an invalid "root".

I think you should use partition type "extended" (0x05) or "extended LBA" (0x0F) in your partition tool instead of "Linux extended" (0x85). If that is not the problem, then your partition table is corrupted, or your disk description is wrong.
If Gujin always follow this message by "trying ... OK", it has probably perfectly recovered and you can continue using it, if it display "trying ... : failed." or "stop.", you should better fix your partition table or your PC BIOS setup as soon as possible.
If such an error appear, the Hard Disk write support is turned OFF automatically, you would better not turn it ON again.
This can appear when the BIOS did not correctly detect the number of heads and sectors-per-track of an older disk, when it is not using the "large" model for accessing the hard disk, or when this hard disk has been partitioned on another PC with another BIOS.
You may be able to change the BIOS setup, for instance not auto detecting the hard disks but giving the values present on the PC where it has been partitioned - try to play there.
There is an error message which may help you in this game:
DISK 0x?? heads, sect/track mismatch: MBR ??/??, BIOS ??/??!

SMART is a protocol which describe the health of you hard disk(s). In short, when newer hard disk (> 1 Gbyte, > ATA3) have a problem writing to the magnetic disk in a certain place, they record this error condition and automatically remap faulty sectors to spare (i.e. hidden) ones.
So you will not notice small errors, and will not loose your data - at least as long as there is spare sectors left!
"Threshold exceeded condition" is a message described in the SMART protocol to say that you should better call your local dealer and get a new drive, because you will soon (or you are already) loosing data because there is no more spare sector - or for any other reason.
Having a disk new enough for the SMART protocol but someone forgot to enable it (the second message) is for me an error - so I report it.
Do not ask me how to enable SMART - I am just writing a bootloader!
Note: Some other operating systems did never care about the SMART status of your disk - but you do not need a bad disk to loose data with them. I may report to you, for the first time, that your hard disk is dying: It is not my fault and I will not pay you a new one -:)
Note also that it is not unusual for a disk to report a strange status on the very first time you ask its SMART status - because it has then to do a lot of scanning. If you see something wrong on the first time you try Gujin, wait few second (until the disk stop colleting its own data) and reboot. If it is still wrong you may begin to talk about discount in your usual shop - the disk may fail in ten minutes or in few years, but it will fail.

It seems that DOS only accept to boot in "simple text mode", i.e. mode 3, 80x25.
Gujin will force mode 3 if it detects that a FAT boot sector is loaded, the message only happen if you boot the MBR of a hard disk, which in turns select a FAT boot sector. Switch to mode 3 as the text mode before booting.
Note: When booting a partition's boot sector, or the Master Boot Record of the disk, Gujin ask to the video card if it supports the standard BIOS calls to display strings in the current (VESA) video mode. If it does, Gujin does not switch to text mode because the user may want to stay in graphic - if it does not support BIOS calls, Gujin switches automatically to the last text mode used.

Do not forget to "enable disk write", else absolutely nothing is written to disks, not even the configuration.

There should not be any problem to boot those, but you have to take care of some Windows restrictions:
• The partition table has to be clean, use FDISK.EXE of Windows to create it. The best way is to use Windows FDISK.EXE on a blank disk to create all partitions at once, this tool will easily create overlapping partition when you try to modify an already existing partition table (I tested that). Plan to leave few unused Mbytes at the end of the disk, they may be _really_ useful later: Plan 16 Mb + 4 Kb free.
• You have to play the best Microsoft games: DLCATT (Drive Letters Changing All The Time). Better install every software on C: - and so you will get a different C: for each Windows boot. Have also a look at file "srdiskid.dat" in the "_restore" hidden directory of the top level directory.
• Windows cannot be installed in an extended partition nor on a secondary hard drive: install it on a primary partition and then copy all files (including hidden files _and_ system files) to the new partition. The order of files is not important (unlike on MSDOS where IO.SYS had to be the first file), but it is easier to copy the files under Linux with "cp -a"
• If your partition is over 8 Gbytes, you have to set its type to be either "Windows FAT 16 LBA" or "Windows FAT 32 LBA". FDISK.EXE will set only partition types "Windows FAT 16" and "Windows FAT 32" for extended partitions, so you need Linux to do that last bit.

To boot DOS or Window95/98/Me, you have to hide some partitions and unhide some others. This is done automagically (when "enable disk write" and "manage visible/hidden partitions" are checked), but you can go in a configuration where none of the primary partition of the first disk are unhidden, and none are "active". Newer BIOSes will then look in the following hard disks to find an "active" partition, but some do not. Simply boot another time with Gujin and then select a FAT operating system on the first disk, still having "enable disk write" checked. Next time you will boot without Gujin, it will get the last OS Gujin has booted. Note: For the auto-hiding feature of Gujin, you need to be able to read and write every hard disks. Windows want to boot on C:, and so if this C: partition is an extended one on the first hard disk, Gujin needs to hide all primaries of every hard disks. There is a two step process, first one is read only - and if everything is OK the write process begins. If you have a broken hard disk as secondary or third drive, Gujin will not be able to read its MBR and it will abort early the process and report you an error (before writing anything), even if you just wanted to boot Win* on the first hard disk and did not care of the third HD.
Moreover, I heard that you cannot have more than one primary partition visible per disk else Win* may be confused, so Gujin will not do that. If you want to try the opposite it is a simple compilation switch.

Gujin uses the video BIOS EDID interface to recognise the screen and select the default video mode resolution. If you know that your screen answer the EDID request, that your screen cable connect the EDID wires, and that your video card has the hardware interface to interrogate your screen, it is possible that your video BIOS has a bug and so do not correctly report the kind of screen you have. Under other operating systems, you will have a floppy or a CDROM to replace the video BIOS - and that extra software may have the bug corrected - but its interface is only working on that other operating system...

First, to modify this comment field of the GZIP kernel, you will need to use the "gzcopy" executable given with Gujin. This "gzcopy" executable only operate on GZIP compatible files, so you either need to use the simple GZIPed kernel (see this FAQ question) or modify the LINUX kernel Makefile (linux/arch/i386/boot/compressed/Makefile) near target "piggy.o:" after line: "gzip -f -9 < $$tmppiggy > $$tmppiggy.gz;"
The resulting file (with comment added) will still be compatible with GZIP and the zlib library - you can use your usual bootloader on the resulting file.
These comment fields are recognised (only hexadecimal) by all configuration of Gujin, but for "maskvesa" and "maskresolution" which need a complete user interface - not available in tiny.exe/tiny.img:

• loadadr=0x00100000 : you can modify the default load address, this will only work with a kernel linked at this address.
  If this field is zero, do not relocate the PIC kernel (EMM alloc'ed memory), very special use.
• runadr=0x00100000 : you can modify the default run address, this will only work with a kernel specially modified.
  If this field is zero, use value of loadadr.
• linux_param_adr=0x00080000 : you can modify the default address to load the Linux parameters, or completely disable the probing (and relocation) by setting it to zero (do not do that now).
  Since 2.4.1, exactly 2.4.0-test3-pre3, this address is configurable in Linux, if a vmlinuz file before 2.4.0 (included) is loaded, this address defaults to 0x90000 - else to 0x80000.
  This address has to be in real mode addressable area (below 0x100000), and if it is exactly 0x90000 (the default for 2.2- kernels), a reset of the PIC is generated before running the kernel. No check is currently done on this value, so keep it quite high (DOS bootloader may be loaded quite high), the theoretical minimum value for the tiny BIOS bootloader is 0x8400 (base) + 30 K (code) + 64K (stack) = 0x20000
• minram=0x00001000 : Minimum number of kilobytes of RAM (hexadecimal only) to have to be able to start the kernel. The default is zero, but anyway another error is generated if the uncompressed kernel does not fit in memory.
  It is the amount of contiguous memory available at 0x100000, i.e. 15 Mbytes if there is a hole at 16 Mbytes.
  
• min_gujin_version=0x0080 : Refuse to load this kernel if the version of Gujin is too low, strictly below the given number.
• option=0x00000000 : The options of this kernel file, none by default.
  This is only taken into account when the setup screen has "ignore kernel IDE options" unchecked, else this field is zero-ed unconditionally.
  Only those bits are currently defined:
  If bit 0 is set, say that this "kernel" file wants the IDE system (hard disks) without the maximum LBA set. It has only to be done when this "kernel" is a safe and standalone IDE aware partition manager. See BEER in ATA T13 D1367.
  If bit 1 is set, say that this "kernel" file wants the IDE system (hard disks) without the disk size set. It has only to be done when this "kernel" is a safe and standalone IDE aware partition manager. See BEER in ATA T13 D1367.
  If bit 2 is set, say that this "kernel" file wants the IDE system (hard disks) with _unfrozen_ passwords - so that it can manage password itself. It has only to be done when this "kernel" is a trusted, safe and standalone IDE manager.
  If bit 3 is set, say that this "kernel" file wants the IDE system (hard disks) with _unfrozen_ overlayed config - so that it can manage this itself. It has only to be done when this "kernel" is a trusted, safe and standalone IDE manager.
  If bit 4 is set, say that this "kernel" file wants the IDE system (hard disks) with Host Protected Area unfrozen.
  If bit 5 is set, say that this "kernel" file wants the IDE system (hard disks) with Host Protected Area unlocked.
  If bit 6 is set, say that this "kernel" file does not want the password for HPA (HPA only password) to be set to the name of the disk in the BEER sector, or to all zero if no BEER detected. It has then to be set another way if Gujin has to lock or freeze the HPA.
  If bit 7 is set, say that this "kernel" file wants the IDE system (hard disks) with hidden Host Protected Area (Is it useful?).
  If bit 8 is set, say that this "kernel" file wants the IDE system (hard disks) with unhidden password.
  
• maskcpu=0x000000F8 : you can declare which microprocessors are _not_ supported by this kernel (if bit (1 << [34567]) set, 80[34567]86 excluded - see the family from CPUID). Some extra bits are used here:
  if bit 31 is set, the kernel cannot run from DOS/windows environment.
  if bit 30 is set, the kernel cannot run from DOS/windows with EMM386 environment.
  
• maskDflags=0x00000000 : Which bit _have_ to be set in cpuid 0x00000001, in edx, for instance "maskDflags=0x00000010" if kernel requires the TSC capability.
• maskCflags=0x00000000 : Which bit _have_ to be set in cpuid 0x00000001 in ecx.
• maskAflags=0x00000000 : Which bit _have_ to be set in cpuid 0x80000001 (AMD processor only).
• maskvesa=0x00000000 : (Only if the loader isn't tiny.exe/tiny.img)
  if bit ([8] - 1) set, VESA [8]BPP supported;
  if bit 16 set, able to boot in text mode;
  if bit 17 set, able to boot in VESA1 mode;
  if bit 18 set, able to boot in VESA2 linear mode;
if bit 19 set, will switch to VESA1 if in VESA2 modes; if bit 20 set, UNable to boot in VGA graphic modes.

• maskresolution=0x00000000 : (Only if the loader isn't tiny.exe/tiny.img)
  if bit set, this resolution (see vmlinuz.h) is supported.

Few other strings are recognised, but they are only needed if the kernel will access the data area of Gujin - i.e. if you want to build a special "my_application.kgz" to do low level stuff: special partitioning software, hardware memory checker, partition backups... without having to load an operating system, but still using graphic video modes, disks and mouse. These future applications will be linked to Gujin in its GPL meaning.

If you do not have parenthesis, the disk cannot do anything special, at least with this interface.
If you have a star, like this: disk 1: EBIOS 0x80, size 40000 Mb (*), 4 partitions. Then the disk contains a B.E.E.R. sector, see:
http://www.t13.org/project/d1367r3.pdf
Gujin uses some data in this sector (shall be mapped in the last 4 Kbytes, i.e. the last 8 sectors of the disk). It uses the "Host Protected Area" and the "reported.sectorperdevice" fields. FIXME: to be described when I understand every bits of it.
Note that setting the "Host Protected Area" may create a difference in between resetting by control-alt-del, by the reset button and by a real power off.
Note also that on a BIOS only PC (no EBIOS), you will probably not be able to read this sector at end of the device...
If you have letters (IDE interface only):

• H: the disk support the "Host Protected Area".
• P: the disk support the "password".
• C: the disk support the "config overlay".
• R: the disk support the "removeable".
• B: the disk support the "SAORAB".

You should have the cdrecord and mkisofs packages installed for this task.
The version I have are: "cdrecord --version" is "Cdrecord-Clone 2.01a19" and "mkisofs -v" is "mkisofs 2.01a17".
It works without problem on my system, I have an ATAPI CDROM and detected the CD rewriter by:
cdrecord -scanbus dev=ATAPI # (and so no "hdc=cdrom" kernel command line parameter)
Then I erased the rewriteable CD I used for testing by:
cdrecord -v dev=ATAPI:0,0 blank=fast # (not to be done for CD-R)
Then I need to decide which floppy size I want to simulate: Bootable CDROM are defined to contain either 1.2 Mbytes, 1.44 Mbytes or 2.88 Mbytes floppy image (or a Hard Disk image - see next question); 360 Kbytes, 720 Kbytes or 1.68 Mbytes are not accepted.
If I want to regenerate from source, I have extracted gujin-0.9.tar.gz in a directory and I type for a 2.88 Mbytes floppy:
make dep boot.288 # double check that instboot is called with --full or -f parameter
I can also use the content of install-*.tgz by typing:
./instboot boot.bin boot.288 --full # you can replace boot.288 by boot.144 or boot.120
With Gujin v0.8, you had to do:
make dep boot.288 INSTBOOT_DEFAULT_PARAMETER=--full
Then I did, to test the floppy behaviour (also done with 1.44Mb and 1.2Mb floppy):
mkdir /tmp/cdrom
cp boot.288 /tmp/cdrom
mkisofs -rock -b boot.288 /tmp/cdrom | cdrecord -v dev=ATAPI:0,0 -
rm -rf /tmp/cdrom
Double check that mkisofs did correctly recognised the simulated boot floppy boot.288 using its size, it shall display: "Size of boot image is 5760 sectors -> Emulating a 2880 kB floppy". Note also that the cdrecord command line finishes by a minus...
I used the current directory "/tmp/cdrom" as a directory to copy on the ISO9660 filesystem of the CDROM, you can use anything, Gujin still cannot analyse the ISO9660 filesystem.
If you would like to put a kernel on the simulated floppy, you will have to use either the mtools package: see /etc/mtools.conf, for instance add a line like:
drive b: file="/home/etienne/projet/gujin/boot.288" exclusive
Then (if you used the right path!) you can do:
$ mdir b:
Volume in drive B is EL-BOOT-V09
Volume Serial Number is 3939-4C45
Directory for B:/

No files
2 779 136 bytes free
$ mcopy /boot/vmlinuz-2.4.20-8 b:
$ mcopy /boot/initrd-2.4.20-8.img b:
$ mdir b:
Volume in drive B is EL-BOOT-V09
Volume Serial Number is 3939-4C45
Directory for B:/

VMLINU~1 20- 1117254 10-24-2003 18:57 vmlinuz-2.4.20-8
INITRD~1 IMG 147277 10-24-2003 18:58 initrd-2.4.20-8.img
2 files 1 264 531 bytes
1 513 472 bytes free
Then you redo the "cp boot.288 /tmp/cdrom" and the following commands
If you do not have (or do not want to use) the mtools package, but can gain root access to mount loop devices, just type as root:
$ mount boot.288 /mnt/floppy -t vfat -o loop
and you can add/remove/list files in /mnt/floppy. Do not forget to "umount /mnt/floppy" before using file "boot.288" in "cp boot.288 /tmp/cdrom".
You can now reboot a PC with this CDROM inserted (and the correct boot order on the PC BIOS).
You can also read the target "CD120FD", "CD144FD" and "CD288FD", and also "CD288FD-late" in Makefile.

Well, the simplest is to ask the boot installer to create a disk image and not a partition image, just by typing:
make proper dep boot.bin instboot
# You can add -w or --verbose parameter to the following line:
./instboot boot.bin ../cd --full -d=BIOS:0x80 --geometry=1032129,63,16,63,512,1032192,0 --mbr-device=../cd
You can then check:
/sbin/fdisk -b 512 -S 63 -H 16 -C 1024 ../cd -lu

Disk ../cd: 0 MB, 0 bytes
16 heads, 63 sectors/track, 1024 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
../cd1 * 63 1032191 516064+ 6 FAT16

Note that giving the option "-d=EBIOS:0x80" would change partition type to 0x0E, i.e. "Win95 FAT16 (LBA)" and use extended BIOS to load Gujin at startup.
Note also that the start of a partition (2nd parameter of --geometry) shall be a multiple of the sectors/track (4th parameter) and the partition size (1st parameter) plus its start (2nd parameter) shall be below (or better equal to) the disk size (6th parameter).
It is better to keep the end of the partition on a cylinder boundary, so if only one partition, its end (1st parameter) is (cylinders * heads * sectors/track - start).
Keep the disk start (7th param) at 0, and the sector size (5th param) to 512 for now...
If you want to increase/decrease the simulated disk size, change the disk size (the last non null parameter of --geometry) keeping it a multiple of 16 * 63 - in my example I had hard_disk_size = 1024*16*63 = 1032192.
For instance, we can generate a 16 Mbytes hard disk like this: 16 * 1024 * 1024 bytes organised in 512 bytes sectors means 32768 sectors - 16 heads and 63 sectors per track means 32 cylinders (rounded down because your FLASH hard drive has this maximum). So the nearest "simple" disk size is 32 * 16 * 63 = 32256 sectors.
Having a start sector multiple of sectors per track means its minimum is 63, so the total size of partition is: 32256 - 63 = 32193. So:
./instboot boot.bin ../cd16Mb --full -d=BIOS:0x80 --geometry=32193,63,16,63,512,32256,0 --mbr-device=../cd16Mb
Note that this example leads to a FAT12 and 4 Kb/cluster (8 Sectors/Cluster) (option --verbose or -w), you could change it if you do not like it by "--fs=FAT:32193,4" so force FAT16 2 Kb/block.
If you want to add files to your simulated hard drive, you just need the mtools package: add a line like:
drive m: file="/home/etienne/projet/cd" offset=32256
to you /etc/mtools.conf (note that 63 * 512 = 32256) and use mcopy, mdir...
WARNING: This is the image of a complete Hard Drive - if you copy that to your Hard Drive using "cp ../cd /dev/hda" you will LOOSE all the data of your hard drive!
Note that only the first partition is created - if you need the 4th partition, use fdisk.
# Then write it on the CDRW:
cdrecord -v dev=ATAPI:0,0 blank=fast
mkdir /tmp/cdrom
ln ../cd /tmp/cdrom/boot.hd # or cp if the file is not too big for you.
mkisofs -rock -hard-disk-boot -b boot.hd /tmp/cdrom | cdrecord dev=ATAPI:0,0 -
# note that disk size is correct: "Size of boot image is 1032192 sectors -> Emulating a hard disk"
rm -rf /tmp/cdrom
In short, the difference between "--geometry=32705,0,16,63,512" and "--geometry=32705,63,16,63,512,32768,0" is that the partition is offseted in the output - so the former is the partition image and the later is the device image. The option "--mbr-device=" adds the bootloader to the device image, else only the partition is bootable: nothing is there to load the partition boot record from the device boot record - "fdisk /mbr" boot record loading the active partition boot record should work when no EBIOS is needed but I did not try it.
You can also read the target "CDsmallHD" and "CDbigHD" in Makefile.
If you do not like the mtools, have right to mount filesystems and directory /mnt/disk exists, you can type:
mount -t vfat /home/etienne/projet/gujin/boot.hd /mnt/disk -o loop,offset=32256 -o umask=0

Are you using an old CDROM driver, with a "speed" of x1, x2 x4 or even time 8 ?
Those CDROM drivers have difficulties reading writeable CDs, that is why standard distribution CDROMs are printed not written.
Also sometimes newer read-only CDROM drivers have problems reading R/W CDROMs.
That is not a software problem, not even a BIOS problem - just get a newer CDROM driver.
There is probably also some compatibility problems with CDROM in DVD readers - I am not a specialist in this area.

If done too early, for instance at startup - before analysis of the BIOS disks, you cannot load a kernel file from this simulated HD or floppy because it has disappeared.
If Gujin does not terminate this emulation, most versions of MS-Windows are seriously confused when simulating floppy because they think the PC has two physical floppy disks drivers...
Note that when this floppy emulation is terminated, the floppy drive letters are changed:
If you have a PC with one and only one floppy, its BIOS disk number is 0x00. When starting the simulated floppy from CDROM, the simulated floppy gets number 0x00 (to be able to boot the PC) and your real floppy becomes 0x01; when the simulation is terminated the BIOS number are back to their initial value.
Same for Hard Disk simulation: the simulated HD get the BIOS number 0x80 and change all the others by adding one to their BIOS number, and the Hard Disk BIOS number changes when simulation is stopped.
If you have a PC with at least two physical floppy drivers, it seems that usually the second one disappear while the CDROM floppy emulation is active. Normally the PC can have a maximum of 4 floppy drives (see _BIOS_equipment_flags(), floppy_present and nb_floppy_less_1 fields) but the limit seems to be two.
If you add USB floppy or FLASH hard disk -> USB adapter with a BIOS which maps those drives as floppy, I'll tell you what happen when you send me the PC... I need a new portable one.
I did not found a logical way to solve all the possibilities, you can configure in the menu whether you do not want the BIOS to terminate the floppy emulation (for instance the simulated hard disk contains a read only DOS partition that you want to boot), whether you want to stop this emulation before Gujin analysis of the content of the disks (so choose early stop, the default) or after the user has chosen a partition to boot (so choose late stop). This emulation is never stopped when booting a kernel (vmlinuz, *.kgz ...) because the stop can be done manually when probing for BIOS parameters, and Linux does not care too much because it will not use BIOS services anyway.
Because the emulated FD/HD on the CDROM is not writable, you use it by giving the parameter "--stop_emulation=<1> stop CDROM emulation 0:never, 1:early, 2:late" to instboot.
What happens when you have two CDROM drivers, each with a bootable CDROM in them, and you terminate the first floppy emulation on the first CDROM to restart the floppy emulation on the second CDROM by saying "the first BOOT attempt fails, find another boot device", is left as an exercise to the reader.

If you have a way to load in memory a file and then start executing it, like a bootable CDROM in non emulation mode, you need "instboot" to generate a Position Independent Code boot file. So:
./instboot boot.bin boot.pic -w
You can examine the content of this file with:
objdump -m i8086 -b binary boot.pic -D | less
or:
objdump --start-address=0x204 -m i8086 -b binary boot.pic -D | less
And you can write this file to the CDROM like:
mkisofs -rock -no-emul-boot -b boot.pic /tmp/cdrom | cdrecord dev=ATAPI:0,0 -
See also target CDnoemul of Makefile.
The execution has to start a the first loaded byte, it will check itself it checksum and copy itself at its own address (relocation of 0 bytes) like files boot.com/boot.exe.
The process to check the complete file checksum is done in the first 512 bytes sector in 80286 compatible code, so the maximum checksum size at a time is 64 Kbytes. That sets a minimum limit in how many dots are displayed on the first Gujin line. You can reduce the checksum calculus size for instance to 16 * 512 = 8 Kbytes by (2880 is not meaningful, head = 0 has the special meaning of max treatment size in sector/track):
./instboot boot.bin /tmp/cdrom/boot.pic --geometry=2880,0,0,16,512 --disk=PIC -w
That would enable you to know where happen the checksum error: if it happen always at the same place, maybe you BIOS did not load the file completely?
The file boot.pic has to be loaded at a segment boundary (base address multiple of 16) in memory accessible in real mode (below 1 Mbyte) and has to be loaded in RAM (to manage its own variable and stack which follow the code segment). The file to load is quite big, bigger than the standard EEPROM of network cards so there is some work if you want to try.
The file boot.pic is also usually too big to be renamed as "IO.SYS" and loaded by the standard DOS partition bootsector - see Makefile for more information on this.

No, you can only create a bootable disk image with a FAT filesystem of any size -:)
./instboot boot.bin boot.144
creates a image of the filesystem of a 1.44 Mb, so you can do:
cat boot.144> /dev/fd0
For a 2.88 Mb floppy image (5760 sectors of 512 bytes, 2 heads, 36 sectors):
./instboot --full --disk=BIOS:0x0 --geometry=5760,0,2,36,512 boot.bin boot.tst
For a 16 Mbytes Hard Disk image without a partition scheme (like a 16 Mb floppy):
./instboot --full --disk=BIOS:0x80 --geometry=32256,0,16,63,512 boot.bin boot.tst
For a 16 Mbytes Hard Disk image with the first partition bootable and a bootable MBR:
./instboot --full --disk=EBIOS:0x80 --geometry=32193,63,16,63,512,32256,0 boot.bin boot.tst --mbr-device=boot.tst
You may change the partition if needed to using fdisk (works on disk images with 16 heads 63 sectors/track).

Well, grab you local keyserver, go and visit: www.keyserver.net:
In short, Key Id: 2D3AF3EA
Fingerprint = 2471 DF64 9DEE 41D4 C8DB 9667 E448 FF8C 2D3A F3EA
Type "gpg --import" and cut & paste the following:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDoLHI4RBACfJqPVwlrq8tyoA0bH/fber7aXYs+dpRH1uucjOhi9zdMAcinA
wDGlLTNbToAF/WwD1+fCQokXzWtbhm5NK4UT2MY0URjuGGJ9VX5EecxwHvx4zRSc
E3jVpj2rtFWRjg6c6LNnyC6K/5qbDpfkxDTgKsc96IW7a9FuqyT0ObDijwCgkRHu
QcKuG3hFivhYtJ+lSRKEniMD/2Ca548GlqOYVJYehEpXba4xbKTtNCS0YPnolnWi
QC3B4bgz+ZbVKH/322dNDmBZ50EgebcZgWEiQFZqgQkFQM8wfnTIa5y+x4LgQO9s
Ge4WRZUHnhTnymbaSM9vA4eLNRghlFO66JmcaxyexQRVtnzn+WXrsqH7cdl32N21
X7XoBACdiyBesbxxq4jNTluG51E2M9qig4kwULV+Xxi6XMOvpy5Kf0Fk/IsXNGix
xI+tajHWXMGo4QgEAP6rlC7qRj+0av22bTt3N/osH5QAZrCO2xZ+upAzx0axPtC9
L1s9pbUZbC9714sOI3v3g+MGGNKhSeTR/8SBmjWCFSkgfN/IlbRCRXRpZW5uZSBM
T1JSQUlOIChHdWppbiBjb3B5cmlnaHQgb3duZXIpIDxldGllbm5lX2xvcnJhaW5A
eWFob28uZnI+iF0EExECAB0FAjoLHI4FCQ0oaIAFCwcKAwQDFQMCAxYCAQIXgAAK
CRDkSP+MLTrz6u2/AKCNScGaa9+V1t/PuH+kuIC5fcCdLACfah7FIGqyUHaA1XOK
k/QpNRh9Kc65AQ0EOgsc1hAEALTFQfw9EUIBzRCbaeRUxXAJuumAJzm79N958vBX
6Qnf9CHLlQIvBAkApRdnDExR+HYRorXTp8QYTGAf8CFL+/M/SR4WJDzPPyOJwJn+
wJUXt0Ch1AW6kjHlLCnpmtTKeeV4PEWT9F9HeYgvihBWpMYWY344/oVqkebj5siG
uc9LAAMFA/9oQo66S9DKXJ0eBg9r34CfPMlPBrP0/7v7x/rq8Lfrudp2Smg4wbuB
czT76HS2w52QsEqkbHDzoNNIUylWpIdwvHgxYs8DyELcw6mjSGkx9LNdbHlgQCZg
2oh7aThQRlb9I/R+ePiRid6mDTLR1Dzhh6/A1p5N5/ONL2K/y4DDnIhMBBgRAgAM
BQI6CxzWBQkNKGiAAAoJEORI/4wtOvPq60YAniw/o8T5G9L/8GLyb56hOWxsuMW9
AJ9VoVFwd4IGw3VWQ7ZfJGacCS5ZBg==
=0TV6
-----END PGP PUBLIC KEY BLOCK-----
You can also get it in file gpg_sign.txt, you will have to remove the minus sign "-" in front of the two lines "-----BEGIN PGP PUBLIC KEY BLOCK-----" and "-----END PGP PUBLIC KEY BLOCK-----": I do not know how they appeared...
You can then verify: "gpg --verify gpg_sign.txt"

• Read and follow the todo list: action to Etienne. -:)
• Fix bugs, clean source and optimise the code size.
• Implement longcall function attribute support (lcallw /lretw) in GCC.
• Support NTFS, reisertfs, UDF filesystem.
• Write an PCMCIA and a USB interface for HD/CDROMs.
• Write a USB interface for keyboards (language interrogation) and mouses.
• Check serial getsize() when bad emulation (and maybe code: ESC [ 100 D )
• Is there (and what is) a problem with soft RAID hard drives?
• Find people speaking other languages to complete file "messages.h"
• serial getcontrol aborted on 'r'
• Check VGA ET400 frequency, code VESA3 refresh?
• Generate a DOS device driver "boot.sys" instead of a "boot.exe" executable? (useful to set it in "config.sys")
• Generate those ide[0-9]=0x... if the DOS boot.exe is used.
• Save parameters to the "boot.exe" file if the DOS boot.exe is used.
• Is there a special procedure to stop Windows95/98 before running the kernel (INT0x2F, ax=0x1609).
• Do a better-looking interface. A penguin should run at 100 mph around the screen showing the user where to click -:)
• Upgrade my English to a better version -:)